Re: a point is being missed
Bruce Montrose (montrose@itd.nrl.navy.mil)
Thu, 9 Nov 1995 09:14:23 -0500
On Wed, 8 Nov 1995, Scott Barman wrote:
> On Mon, 6 Nov 1995, Casper Dik wrote:
>
> > Let me say first that I don't speak for SunSoft. This doesn't
> > change the fact that it is nearly impossible to do static linking
> > on Solaris 2.x. (And static dynamic linking is a slip of the keyboard).
>
> Unfortunatly, it is attitudes like this that will prevent Solaris from
> ever being able to statically link binaries. This attitude seems to be
> prevelant among all my contacts with Sun.
If enough of us voice our opinions as you have done so elloquently in
this message then maybe they will respond.
>
> > I have not yet seen any good arguments against dynamic linking.
>
> Anonymous FTP: So you can put a copy of "ls" in the chroot area without
> having to copy, and expose, the libraries. So you can include a program
> that will allow the user to search your archive (see the "quote site
> index" command for gatekeeper.dec.com) again, without exposing your
> libraries to attack. Another example later.
>
These have been mentioned before but sometimes people need to be told
things many times before they listen. I would like to add my own reason
to the list: I'm against all forms of censorship and I think that it is
inappropriate for Sun to limit our options so that we are forced to do
what they feel we should be doing.
They could still ship their product out with dynamically linked login and
whatever else they choose to do, but they could at least provide the means
for others to easily replace these with static versions by the client's own
discretion.
> > Environment variables and other environmentel tricks have always been
> > possible in Unix. The LD* variables have made the need for
> > environmental control much more obvious. su/login/sendmail didn't
> > do proper cleanup and passed almost any environment variable to
> > sub processes. That was not a problem introduced by dynamic linking.
> > It was a problem that had existed for a long time but that had gone largely
> > unnoticed. Even $TERM is dangerous in some circumstances.
>
> Dynamic linking adds exposure to another aspect of your system. Leave
> the libraries open for attack through a program that has to run setuid
> or setgid and they will be attacked. Maybe not now, but they will be.
>
STANDARD_COMMENT:
Sometimes the obvious needs to be repeated often before it sinks in.
> > First of all: all authentication programs are extensible through dynamic
> > linking, all localized programs are extensible through dynamic linking,
> > etc. Dynamic linking is required.
>
> "Extensible through dynamic linking"? How so? Please explain? What
> are we going to do, leave it dynamic so login user can add their own
> options on the fly? Sounds real secure to me!
>
Hello. Anybody home here? I'm surprised that Sun would try this line on
the group of individuals that recieve this mailing list. This is something
that I expect to see (and do see often) on television commercials where
sadly most of the American public assimilate the information directly as
being factual without question.
> > >No, I'm sorry, Sun may be unwilling to go to the trouble to link login
> > >static (and indeed, they probably are - they've demonstrated an
> > >unwillingness to go to any sort of trouble for the sake of security
> > >until prodded by wide publicity of a problem). But claiming that
> > >they're unable to just doesn't hold up.
> >
> > You're being unfair. Sun is pretty open about security. We publish
> > security patches for problems not widely know.
>
> Gee... then why hasn't Sun done something about sendmail so we can get
> off the sendmail advisory of the month club??
>
True, but lets not be drawn into another debate. Keep focused on the
issue of statically bound censorship. A common tactic for a debater with
a weak argument is to introduce other issues to drift away from or
confuse the real issues of the debate.
> > Besides, I don't share you opinion that linking login statically contributes
> > to the security of Solaris 2.x.
>
> It limits the attackable objects to one item, which can be secured far
> better than the program plus EIGHT libraries currently being used by the
> Solaris 2.4 login program. What's easier to tie down, nine items or one?
>
> Oh... and a program, like login, can be made to be executable only (no
> read permissions). You cannot have dynamic libraries without read
> permissions, dlopen() will fail (I just tried that one!). So I can
> better secure login but not the libraries.
>
goto STANDARD_COMMENT;
> > In Solaris 2.6, what would you rather have: a statically linked login or
> > a totally dynamically configurable login?
>
> Sun, or anyone else, can make login configurable with a statically
> linked program. Having something configurable is NOT does not mean
> having to be dynamically linked!
>
> Besides, what kind of configuration options do you need? There are
> parameters in /etc/default/login that pretty much covers everything
> (with some exceptions I think would be worth looking into). Do you need
> a dynamic library to process that file? I don't think so!
>
goto STANDARD_COMMENT;
> scott barman
> --
> scott barman DISCLAIMER: I speak to anyone who will listen,
> scott@disclosure.com and I speak only for myself.
> barman@ix.netcom.com
> "I don't know if security explains why the Win95 support Web servers run BSDI
> 2.0--an Intel-based Unix--rather than Windows NT, which Microsoft insists is
> the ideal Web software solution. Does Redmond know something we don't know?"
> -Robert X. Cringely, INFORWORLD, 9/11/95
>
These comments are my own and in no way are meant to represent the
opinions of my place of employment.
_______________________________________________________________________________
_/_/ _/_/ _/_/_/_/ _/_/ NAVAL RESEARCH LABORATORY
_/_/_/ _/_/ _/_/ _/ _/_/ Center for High Assurance Computer Systems
_/_/_/_/ _/_/ _/_/ _/_/ _/_/ Mail Code 5542
_/_/ _/_/_/ _/_/_/_/ _/_/ 4555 Overlook Ave., S.W.
_/_/ _/_/ _/_/ _/_/ _/_/_/_/ Washington, D.C. 20375-5337
_______________________________________________________________________________
Bruce E. Montrose Phone: (202)767-0485 Bldg: 16
Fax: (202)404-7942 Room: 215
_______________________________________________________________________________